Overview of Dune’s Decoded Data Approach
Dune uses the ABI (Application Binary Interface) of smart contracts to decode blockchain transactions into structured tables. Each event log and function call from the ABI are parsed into their own tables. This decoding process transforms the raw, encoded data on the blockchain into human-readable tables, simplifying the analysis of smart contract data. Dune’s decoded data approach offers several benefits:- Enhanced Readability: The decoded data tables provide a clear and intuitive representation of smart contract activities
- Efficient Analysis: The structured tables enable efficient querying and analysis of smart contract data
- Handling Multiple Contract Instances: For smart contracts with multiple instances, Dune aggregates the data from these instances into a single table, simplifying the analysis process.
- Collaborative Mapping: Dune’s smart contract library is continuously expanded through the active participation of the Dune community, ensuring that the decoding coverage remains comprehensive and current.
Which contracts have decoded data?
Contract submission on Dune are driven by the community. Usually the odds are good that the contract you are looking at is already decoded, but esepecially for new projects or new contracts, it might be that the contract is not decoded yet. In those cases you can submit the contract to be decoded. Decoding usually takes about 24 hours, in special cases it might take longer. You can check if contracts are already decoded by querying[blockchain].contracts
tables, the data explorer or use this dashboard.
If you want to submit several contracts at the same time, there is also the possibility of submitting a batch of contracts. To do so, please use this CSV as a template and fill it in with the appropriate information for the contracts you want to decode. Afterwards send the CSV to decoding@dune.com.
How does decoding work?
Smart Contracts on any EVM blockchain are mostly written in high level languages like Solidity or Vyper. In order for them to be able to be deployed to an EVM execution environment, they need to be compiled to EVM executable bytecode. Once deployed, the bytecode gets associated to an address on the respective chain and is permanently stored in this chain’s state storage. To be able to interact with this smart contract, which is now just bytecode, we need a guide to be able to call the functions which are defined in the high-level languages. This translation of names and arguments into byte representation is done using an Application Binary Interface (ABI). The ABI documents names, types, and arguments precisely which allows us to interact with the smart contract using a somewhat human readable format. The ABI can be compiled using the high level language source code. The ABI is used to call a smart contract or interpret the data it emits.
Decoding Example
We are going to look at an event log of an ERC20 transfer event from the smart contract that represents the $PICKLE token. On Etherscan the undecoded event looks like this:
ethereum.logs
table in the Dune database, we will receive the same encoded bytecode as our result dataset.
pickle_finance_ethereum.PickleToken_evt_Transfer
table to access the decoded event log.
Transfer
event log of an ERC20 token will always be:
address
(32bytes) and are respectively the sender and recipient of the token transfer. An event log only has 3 indexed fields, so the data
field is used to store the information about how much units of the token have been moved in this transaction. This field is called value
.
Since topic0
always is just the Keccak-256 hash of the signature of the event, we are left with decoding topic1
, topic2
and data
.
In this case, they map out like this:
raw data field | decoded data description | raw data | decoded data |
---|---|---|---|
topic0 | keccak(‘Transfer(address,address,uint256”)) | 0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef | not needed, this table only contains event logs from the transfer event log |
topic1 | from | 0x00000000000000000000000075e89d5979e4f6fba9f97c104c2f0afb3f1dcb88 | 0x75e89d5979e4f6fba9f97c104c2f0afb3f1dcb88 |
topic2 | to | 0x00000000000000000000000087d9da48db6e1f925cb67d3b7d2a292846c24cf7 | 0x87d9da48db6e1f925cb67d3b7d2a292846c24cf7 |
data | value | 0x00000000000000000000000000000000000000000000001a894d51f85cb08000 | 489509000000000000000 |